Day2，我透過Antigravity 檢查專案文件，找出小菜蛾施藥時機、青江菜追肥排程，以及農藥作用機制輪替門檻等問題。今天，我準備進一步處理其中一項重要的產品設計難題：

當系統查不到農藥的安全採收期時，應該直接擋下推薦，還是顯示警示，交由農民自行判斷？

這看似只是介面要顯示哪一句話，背後卻牽涉食安風險、使用體驗，以及AI系統的責任界線。如果系統直接擋下，可以降低誤用風險，但也可能因為資料暫時缺漏，讓農民無法繼續操作；如果只顯示警示，雖然保留使用彈性，卻可能讓使用者忽略風險，誤以為系統推薦的農藥都能安全使用。

我請 Gemini 協助查找農業部農藥資訊服務網、官方用藥指引及相關公開資料，確認「未標示安全採收期」可能代表哪些情況，例如資料缺漏、適用條件不同，或該藥劑不適用於目前設定的作物。

接著，再讓 Antigravity 比對 README、規則文件與系統流程，找出目前在哪些步驟可能出現資料不完整的情況，
ANTIGRAVITY 說:
面對這個產品設計難題，最佳的處理方式是採行**「分級智慧防護模式 (Hybrid Model)」**，避開「全一律硬攔截」或「全一律軟警告」的極端思考。

關鍵在於：當系統查不到 PHI 時，必須先辨識「查不到的原因」，再給予對應的處置與 UX 互動。

💡 核心處理策略：三分法防護機制 (Tri-Rule Engine)
建議將「查不到安全採收期」拆解為以下三種具體情境進行分流處理： ┌─ 1. 未登記用藥 (UNREGISTERED) ───────► 🔴 強制硬攔截 (Hard Block) │ 農藥無 PHI 數據 ────┼─ 2. 資料庫缺漏 (MISSING_DATA) ────────► 🟡 警示放行 + 強制實名紙本核對 │ └─ 3. 免訂採收期 (EXEMPT) ─────────────► 🟢 綠色通道放行 (Pass)

1. 🔴 非登記用藥 (UNREGISTERED) ➔ 100% 強制硬攔截
   情境：該藥劑根本未核准登記於青江菜（小葉菜類）。
   處理：系統硬性阻斷推薦與計算，並顯示紅條警示。這屬於違規用藥風險，完全不能交給使用者自行判斷。
   責任界線：系統負起食安第一線防衛責任。
2. 🟡 資料庫缺漏 (MISSING_DATA) ➔ 警示放行 + 人工雙重核對 (Soft Warning & Verify)
   情境：藥劑確實核准用於該作物，但因 API 更新時差或資料庫欄位缺漏無 PHI 數值。
   處理：保留查詢結果，但搭配黃色/橘色警示標籤，並觸發「二次實名確認彈窗」，要求農民：
   對照實體農藥瓶身/包裝標籤。
   手動勾選「已確認實體標籤之安全採收期」後方可計算排程。
   責任界線：釐清「系統提醒」與「實體標籤權威性」，兼顧實用性與風險控制。
3. 🟢 免訂採收期 (EXEMPT) ➔ 綠色通道正常放行
   情境：生物防治劑（如蘇力菌 Bacillus thuringiensis、印楝素等天然物質），依法規屬 MRL 豁免。
   處理：直接標記「🟢 免訂安全採收期 (MRL豁免)」，避免誤判為數據缺失而阻斷農民使用低風險好藥。